Modulupdate in mandantenfähigen Installationen

Der Modulupdate in mandantenfähigen Installtion findet in einer SuperX-Installation statt, allerdings werden die einzelnen Scripte mit unterschiedlichen Umgebungsvariablen, wie sie in SQL_ENV.<<MANDANTID>> definiert ist, z.B. SQL_ENV.FHRO.

In der SQL_ENV.<<MANDANTID>> werden unterschiedliche Pfade für den jeweiligen *_LOAD_PFAD gesetzt, wobei in der Regel die Mandandid ein Unterverzeichnis vom "normalen" LOAD_PFAD ist. So ist z.B. beim COB-Modul folgender Pfad anzusetzen:

Normale SuperX-Installation:
COB_LOAD_PFAD=$SUPERX_DIR/db/module/cob/rohdaten

Mandantenfähige SuperX-Installation:
COB_LOAD_PFAD=$SUPERX_DIR/db/module/cob/rohdaten/FHRO

Unterhalb von FHRO befindet sich noch einmal die Entladeroutine sowie das Unterverzeichnis unl mit den Rohdaten. Dieses Verzeichnis FHRO kann der Einfahheit halber auch ein symbolischer Link auf den gemounteten COB-Rechner sein.

Durch Setzen der Mandantennummer in der Umgebungsvariable MANDANTID in der jeweiligen SQL_ENV des Mandanten werden die ETL-Scripte anders ausgeführt: Die Logdateien werden jeweils mit der Mandantennummer versehen (z.B. L_cob_updateFHRO.log), damit die Übersicht nicht verloren geht und der gleichzeitige Update mehrerer Mandanten in eine rsuperX-Installation möglich ist.

Außerdem können weitreichende Steuerungsmechanismen im Modulupdate eingesetzt werden: Nach jedem ETL-Schritt können optional mandantenspezifische Scripte aufgerufen werden. Diese müssen folgende Namenskonvention einhalten:

<<Scriptname>>_<<MANDANTID>>.sql

Also für eine hochschulspezifische Transformation im COB-Modul des Mandanten FHRO wird eine Datei namens

cob_trans_FHRO.sql

mit entsprechenden SQL-Anweisungen angelegt.

Seite 192 / 257
Letzter Update: 07.06.2007
Impressum